-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify new line indicator and message badge #10582
Conversation
Web-Expensify
34696] Simplify new line indicator and message badge
This PR is required to test atm as I discovered a regression caused by the |
This is still on HOLD but testing well so marking it as ready. |
@@ -11,14 +11,8 @@ import withLocalize, {withLocalizePropTypes} from '../../../../components/withLo | |||
import FloatingMessageCounterContainer from './FloatingMessageCounterContainer'; | |||
|
|||
const propTypes = { | |||
/** Count of new messages to show in the badge */ | |||
count: PropTypes.number, | |||
|
|||
/** Whether the marker is active */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** Whether the marker is active */ | |
/** Whether the New Messages indicator is active */ |
Should we rename this file since it's no longer showing counts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed the comment below this but going to raise a separate PR to clean up the file naming
|
||
/** Callback to be called when user closes the badge */ | ||
onClose: PropTypes.func, | ||
isActive: PropTypes.bool, | ||
|
||
/** Callback to be called when user clicks the marker */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** Callback to be called when user clicks the marker */ | |
/** Callback to be called when user clicks the New Messages indicator */ |
Not sure if these comments were copy paste from the new messages marker, or if we're calling both things a marker, but I think it's good to differentiate for clarity
</Text> | ||
</View> | ||
)} | ||
shouldRemoveRightBorderRadius | ||
/> | ||
<Button |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean the new messages indicator can't be closed with an X
? Why the change? Just curious
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Largely just a matter of simplification and nobody fought to keep it. In the new design, the visibility of the component is enabled based on these conditions alone:
- The new marker is set
- The user is scrolled up past a certain distance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it's something we'll miss? Should be relatively easy to add it back in if so. I kinda found it just made the code harder to understand and not really all that useful of a feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I like this change actually, this was just my first time looking at this code, and this is a change I "picked up" that I wasn't expecting, and I wanted to make sure I understood it correctly, since I'm still kind of a noob when it comes to reviews in App
@@ -134,8 +134,8 @@ class ReportActionsList extends React.Component { | |||
item, | |||
index, | |||
}) { | |||
const shouldDisplayNewIndicator = this.props.report.newMarkerSequenceNumber > 0 | |||
&& item.action.sequenceNumber === this.props.report.newMarkerSequenceNumber; | |||
const shouldDisplayNewIndicator = this.props.newMarkerSequenceNumber > 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the first condition needed here? can both sequenceNumber
and newMarkerSequenceNumber
be equal to zero simultaneously?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we explicitly set this to zero, could we set to null to indicate the lack of a value here instead? NAB but since zero could be a valid sequence number (just based on the data type), null could be a little cleaner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I understand the question. But the newMarkerSequenceNumber can be equal to zero and the created action has a sequenceNumber of 0. So we do this to avoid showing the marker for the "created" action. We don't want to show the marker when the last read sequenceNumber is 0.
As for using null
instead, I don't have strong feelings on it, but maybe we can add a comment here at least to explain what I just mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if this comment helps. Or if you feel strongly that we should use null
. I'm inclined to leave it since everything is working well for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment makes sense to me, so I agree it's 👌 to leave it using 0
@@ -174,53 +176,79 @@ class ReportActionsView extends React.Component { | |||
} | |||
|
|||
componentDidUpdate(prevProps) { | |||
const isReportFullyVisible = this.getIsReportFullyVisible(); | |||
|
|||
// NETWORK CHANGE DETECTED |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan of these capitalized comments, can we make them lowercase and keep consistency with all other comments, or use variable to communicate this? Eg,
const bool wasNetworkChangeDetected = lodashGet(prevProps.network, 'isOffline') && !lodashGet(this.props.network, 'isOffline');
...
if (wasNetworkChangeDetected) {
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the comments I wanted to create a sense that these are discrete "events" or "situations" we might encounter.
I had a draft where each of these was moved to a method like checkIfNetworkChangedAndRefetch()
, but that felt like something Uncle Bob would do and maybe overkill. I eventually just decided to do something obvious and ugly. Will try the variable thing! Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making these comments not be all uppercase already solves my concern. I think we should follow our guidelines, so others can as well. If we break consistency for our comments, contributors may start doing the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And to be clear, I did appreciate the comments that are in this code, as it would've been much harder to follow without them
// REPORT PREVIOUSLY HIDDEN BY SIDEBAR/LHN OR VIEW EXPANDED FROM MOBILE TO DESKTOP LAYOUT | ||
// We update the new marker position, mark the report as read, and fetch new report actions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// REPORT PREVIOUSLY HIDDEN BY SIDEBAR/LHN OR VIEW EXPANDED FROM MOBILE TO DESKTOP LAYOUT | |
// We update the new marker position, mark the report as read, and fetch new report actions | |
// If the report was previously hidden by the side bar, or the view is expanded from mobile to desktop layout | |
// we update the new marker position, mark the report as read, and fetch new report actions |
Report.openReport(this.props.report.reportID); | ||
} | ||
|
||
// REPORT PREVIOUSLY OPEN BUT USER NAVIGATED TO SIDEBAR/LHN | ||
// When the user swipes back on the report or navigates to the LHN the ReportActionsView doesn’t unmount and just remains hidden. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How's "swipes back on the report" different from "navigates to the LHN"?
// When the user swipes back on the report or navigates to the LHN the ReportActionsView doesn’t unmount and just remains hidden. | |
// When the user swipes back on the report or navigates to the LHN the ReportActionsView doesn't unmount and just remains hidden. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll be more general here. I meant swipe or tap the back button. Both would be ways of navigating to the LHN.
Report.openReport(this.props.report.reportID); | ||
} | ||
|
||
// REPORT PREVIOUSLY OPEN BUT USER NAVIGATED TO SIDEBAR/LHN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// REPORT PREVIOUSLY OPEN BUT USER NAVIGATED TO SIDEBAR/LHN |
} | ||
|
||
// REPORT COMMENT MANUALLY MARKED AS UNREAD | ||
// Checks to see if a report comment has been manually "marked as read". All other times when the lastReadSequenceNumber |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Checks to see if a report comment has been manually "marked as read". All other times when the lastReadSequenceNumber | |
// Checks to see if a report comment has been manually "marked as unread". All other times when the lastReadSequenceNumber |
this.setState({newMarkerSequenceNumber: 0}); | ||
} | ||
|
||
// REPORT COMMENT MANUALLY MARKED AS UNREAD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// REPORT COMMENT MANUALLY MARKED AS UNREAD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a lot of context for these changes, but they test well for me locally, and the logic and comments make sense to me
@@ -134,8 +134,8 @@ class ReportActionsList extends React.Component { | |||
item, | |||
index, | |||
}) { | |||
const shouldDisplayNewIndicator = this.props.report.newMarkerSequenceNumber > 0 | |||
&& item.action.sequenceNumber === this.props.report.newMarkerSequenceNumber; | |||
const shouldDisplayNewIndicator = this.props.newMarkerSequenceNumber > 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment makes sense to me, so I agree it's 👌 to leave it using 0
Web-Expensify
34696] Simplify new line indicator and message badge
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by @marcaaron in version: 1.1.96-0 🚀
|
Going to try reverting this to see if it's the cause for #10751 |
Details
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/224876
Tests
PR Review Checklist
Contributor (PR Author) Checklist
### Fixed Issues
section aboveTests
sectionQA steps
sectiontoggleReport
and notonIconClick
)src/languages/*
filesSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
displayName
propertythis
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed
### Fixed Issues
section aboveTests
sectionQA steps
sectiontoggleReport
and notonIconClick
).src/languages/*
filesSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
have been tested & I retested again)/** comment above it */
displayName
propertythis
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)QA Steps
Same as Test Steps
Screenshots
Web
Mobile Web
Desktop
iOS
Android